Connnecting TUI and GUI

Connnecting TUI and GUI

A configuration by text files, and a GUI settings window for the same, are not so different, aside from the fact that a plain configuration file may also show parts of the scripting lanugage, which may not be relevant to the end user. Also, a single configuration file may contain too much information and overload the user, as compared to a settings GUI which is more neatly organized.

The problem can be solved by firstly splitting the configuration file into separate files by context, thereby containing only configurations relevant to the desired context, and connecting those files to other contexts by importing them. Additionally, the configurations can be stored as specific variables, without including the parts of the scripting language, which makes it easier for the end user to configure. This is ususally done by using INI files (in Windows), YAML or TOML files. Configurations using JSON, Lua, Scheme/Guile or Nix are different from this as they include parts of the scripting language in them.

Additionally, a settings GUI also helps the user by letting them navigate easily to other parts of the configuration, where as in a text based UI, the user will have to know which file to open next. In a settings GUI, these can be accessed from a sidebar, address bar or the navigation bar. In a text based UI, this can be implemented either by having a reference text file, which is often provided by a package with its manpages, or by having comments to locations of related configuration files in each file, which resembles the ease of a settings GUI better. But compared to a settings GUI, this results in redundancy as the comments have to be rewritten into each file. Dynamic loading can be implemented, but that would have to be in the manpages, and not in the text configuration file. Manpages are written in a typesetting language called troff (typesetter roff), which is a language based on the roff family of typesetting markup languages, inspired by runoff.

Also, this does allow the user to jump between configuration files easily, but instead, the user has to close the current file, and has to manually open the other file. The only solution to that is to create a full fledged menu with a text UI and syntax highlighting, with keyboard based navigation. If one were to prefer inputs from other devices like the mouse, and maybe add a skeumorphic UI to it, it's already turned into a GUI program. Then, it will depend on the nature of the window manager as to whether it resembles a traditional GUI program with its own headerbar and window control buttons.

In any case, help documents or guides of any other form are very important to any new product or service. Even though manpages exist, they may not always be the best for of documentation for all users. To find the best form of documentation, aside from philosophy, one can also take at historic forms of documentation used by corporate products that have captured the attention of users. That doesn't mean their success was due to their product quality, it's just that they invested a lot into marketing, and because of that, they did well in capturing the attention of users.

Linux distributions for example could take the approach of Deepin Linux or Ubuntu Budgie in teaching users about the system by including a welcome program, which was something that Microsoft XP and 98 excelled at.